During the operation of a platform, it is highly desirable to have continuous uptime or continuous accessibility of the platform. The ability of the platform to run continuously is important to end users and is especially important to the enterprise because it may affect the operations of the enterprise. The uptime and reliability of a platform is often measured and referred to as the 5 9's, i.e. 99.999% availability. In the enterprise, when a platform is unavailable for greater than 5¼ minutes in one year, it cannot be designated as meeting the 5 9's. The sale of a platform targeted for the enterprise is often determined by the ability of the platform to meet the 5 9's.
One of the factors affecting the uptime of a platform is the need to restart or reset the platform. When the platform is being restarted, the time taken for the restart is considered as downtime and it affects the availability of the platform. Some of the myriad reasons for the need to restart the platform include re-initializing the operating system (OS) running on the platform due to the loading of new OS drivers, new software or new software patches. The OS may determine that it needs to restart the platform to update its registry keys or to restart the OS environment.
However, in certain instances, it may not be necessary to restart the whole platform to allow the OS to update its registry keys or to restart the OS environment. In one instance, when there are no hardware changes to the platform and when only software changes to the platform are required, it is not necessary to restart the whole platform and reinitialize all the hardware again. Conventional platforms, however, perform a full platform reset even when there are no hardware changes to the platform and when only software changes to the platform are required.
FIG. 1A depicts a prior art restart sequence 100 of a conventional platform that supports legacy based basic input/output system (BIOS). Timeline 105 shows a time reference of the restart sequence 100. When the conventional platform is powered on at time 0, it enters the phase 110 of early initialization. In the phase 110, the central processing unit (CPU) is powered up and it executes the BIOS code that resides at its reset vector. The BIOS may perform basic checks of the platform such as power on self tests (POST) and memory tests. After the checks are done, the BIOS initiates the next phase 115 of hardware initialization. The BIOS detects the IO devices connected or plugged in the platform and performs initialization tasks such as peripheral component interconnect (PCI) enumeration, launching option read only memory (ROM) or polling IO devices in the phase 115.
When the phase 115 of hardware initialization is completed, the OS is launched in the phase 120. During the operation of the platform, a software initiated reset request or a warm reset may be encountered. Phase 125 depicts the platform receiving a warm reset request. On receipt of the warm reset request, the platform performs a full platform reset and enters again the phase 130 of early initialization, the phase 135 of hardware initialization and the phase 140 of launching the OS.